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Foreword 


ISO (the International Organization for Standardization) and IEC (the International Electrotechnical 
Commission) form the specialized system for worldwide standardization. National bodies that are 
members of ISO or IEC participate in the development of International Standards through technical 
committees established by the respective organization to deal with particular fields of technical activity. 
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, 
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. 


The procedures used to develop this document and those intended for its further maintenance are described 
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types 
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/ 


IEC Directives, Part 2 (see www.iso.org/directives ог www.iec.ch/members_experts/refdocs). 


ISO and IEC draw attention to the possibility that the implementation of this document may involve the 
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any 
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not 
received notice of (a) patent(s) which may be required to implement this document. However, implementers 
are cautioned that this may not represent the latest information, which may be obtained from the patent 
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held 
responsible for identifying any or all such patent rights. 


Any trade name used in this document is information given for the convenience of users and does not 
constitute an endorsement. 


For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions 
related to conformity assessment, as well as information about ISO's adherence to the World Trade 
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see 

In the IEC, see = 


This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, 
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information. 


This second edition cancels and replaces the first edition (ISO/IEC 18181-2:2021), which has been technically 
revised. 


The main changes are as follows: 

— Cross-references to ISO/IEC 18181-1 are updated to match its second edition; 

— The JPEG bitstream reconstruction procedure was moved to Annex A and revised to improve clarity; 
— Annex B was added, specifying the image/jx1 media type registration. 

A list of all parts in the ISO/IEC 18181 series can be found on the ISO and IEC websites. 


Any feedback or questions on this document should be directed to the user's national standards 
body. А complete listing of these bodies can be found at www.iso.org/members.html and 
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Information technology — JPEG XL image coding system — 


Part 2: 
File format 


1 Scope 


This document specifies the transport and container formats for JPEG XL codestreams as specified in 
ISO/IEC 18181-1. This document specifies how to add metadata and extensions to JPEG XL codestreams. A 
file as described by this document is called a JPEG XL file. 


2 Normative references 


The following documents are referred to in the text in such a way that some or all of their content constitutes 
requirements of this document. For dated references, only the edition cited applies. For undated references, 
the latest edition of the referenced document (including any amendments) applies. 


ISO/IEC 18181-1:2024, Information technology — JPEG XL Image Coding System — Part 1: Core coding system 


ISO/IEC 10918-1:1994, Information technology — Digital compression and coding of continuous-tone still 
images: Requirements and guidelines 


ISO/IEC 19566-5, Information technologies — JPEG systems — Part 5: JPEG universal metadata box format (JUMBF) 
IETF RFC 7932, Brotli Compressed Data Format!) 


3 Terms and definitions 
For the purposes of this document, the following terms and definitions apply. 


ISO and IEC maintain terminology databases for use in standardization at the following addresses: 


— ISO Online browsing platform: available at https://www.iso.org/obp 
— IEC Electropedia: available at https://www.electropedia.org/ 


3.1 
box 
structured collection of data describing the image or the image decoding process 


3.2 
box content 
data wrapped within the box structure 


3.3 


box type 
kind of information stored within the box 


3.4 
file format 
set of data structures for the storage of metadata and extensions of a codestream 


1) https://www.rfc-editor.org/info/rfc7932 
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3.5 
JPEG XL file 
data file encoded in the file format defined by this document 


3.6 
superbox 
box that carries other boxes as payload data 


4 General 
This document defines the file format of a JPEG XL file. 


A JPEG XL file shall contain a codestream as specified in ISO/IEC 18181-1 and may contain additional 
metadata and extensions. 


A JPEG XL file shall come in one of the following forms: 
— Abox structure, as defined in Clause 5; 
— Adirect JPEG XL codestream without box structure. 


The rest of this document only defines the box structure, the codestream without box structure is valid but 
is completely specified in ISO/IEC 18181-1. 


A decoder shall require the file format to follow either the structure of a codestream without box structure, 
or follow the box structure as defined in Clause 5 and follow all box requirements in Clauses 6 to 9. A 
decoder can extract the codestream from the box structure and decode the image from the codestream 
using the procedure specified in ISO/IEC 18181-1 and can decode the contents of other boxes following their 
respective specifications in this document. 


NOTE A direct JPEG XL codestream without box structure is also a valid JPEG XL file. This allows, for example, a 
more efficient encoding of images for the web, in cases where information encoded in other boxes than the codestream 
is not required. 


The JPEG XL media type registration for image/jx1 is specified in Annex B. 


5 File organization 


A JPEG XL file using the box structure is formed as a series of boxes. These boxes contain all data within the 
file, including the initial signature required by the file format. 


NOTE This box-based file format is based on the same syntax as described in ISO/IEC 15444-1:2019, Annex | or 
ISO/IEC 15444-2:2021, Annex M, or ISO/IEC 21122-3. The binary format of a box is also described in Clause 8. 


Boxes of different types contain different types of data, such as the file signature, metadata and the 
codestream. Clause 9 defines box types that may appear in a JPEG XL file and their requirements. Boxes with 
an unrecognized type shall be ignored and skipped by the decoder. 


AJPEG XL file shall contain a JPEG XL codestream. The codestream can be split across multiple boxes: JPEG 
XL partial codestream boxes. In this case, the codestream is formed by the concatenation of the content of all 
those boxes. 


Any boxes, content and codestreams present in a superbox, such as another JPEG XL file іп а JUMBF superbox, 
shall not be taken into account for the syntactic requirements of this document; they recursively follow their 
applicable specification. 


Tables 1 and 2 each show a conceptual box structure of a JPEG XL file, that is a possible series of different box 
types that form the file, respectively with a single full codestream box and with multiple partial codestream 
boxes. Boxes that may appear multiple times are indicated with optional boxes are indicated with 
brackets and required boxes are indicated in bold. These figures are only an indication and do not imply 
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any ordering or counting requirements for the boxes. The decoder shall not make any assumptions about the 
ordering of any boxes after the first two, except where indicated. 


Table 1 — Conceptual structure (example) of a JPEG XL file using a full codestream box 


JPEG XL Signature box 
File Type box 

Level box 

(JPEG XL Frame Index box) 

JPEG XL Codestream box 

(JUMBF box)... 

(Brotli-compressed box containing Exif) 
(XML box) ... 

(Brotli-compressed box containing XML) 
(JPEG Bitstream Reconstruction box) 


Table 2 — Conceptual structure (example) of a JPEG XL file using partial codestream boxes 


JPEG XL Signature box 
File Type box 

JPEG XL Partial Codestream box ... 
(PEG XL Frame Index box) 

JPEG XL Partial Codestream box ... 
(JUMBF box) ... 

(Exif box) 

JPEG XL Partial Codestream box ... 
(XML bow) ... 


6 Data types and numerical values 

Data types used in this document shall be interpreted by the decoder as follows: 
— U32: a 32-bit unsigned integer encoded in big endian order (4 bytes). 

— u64:a 64-bit unsigned integer encoded in big endian order (8 bytes). 


— Varint(): an unsigned integer value of up to 63 bits as a variable length integer in little endian order as 
specified in ISO/IEC 18181-1:2024, E.4.2. 


— 0320), u(n), Bool: as specified in ISO/IEC 18181-1:2024, B.2. 


Numerical values for bytes are given as hexadecimal values, each individually prefixed by 0x. Hexadecimal 
byte values are given in the order as they appear in the file. In some cases, these bytes spell out text in ASCII, 
this is informatively indicated after the hexadecimal values. 


7 Graphical descriptions 


Box definitions contain graphical description tables to illustrate the structure of the box. These tables 
should be interpreted as follows. 


— Asequence of columns is used to indicate the fields of the box and their order (from left to right). 


— Optional fields are indicated with brackets. 
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— Underline indicates a variable length field. Exact data types or sizes are indicated by name either in the 
rectangle after the name of the field, or in a description of the fields outside of the table. 


— Multi-column headers may show fields that are grouped in a larger named structure. 
‘Table 3 shows an example of a box with 3 fields: 

— A: a name given to a group of the three fields contained within. 

— В: required field with а fixed length data type: the type u32 

— C: optional field with a fixed length data type (e.g. u32, u64 or a fixed amount of bytes) 


— D: required field with a variable length data type (such as Varint(), or remaining amount of bytes) 


Table 3 — Example ofa graphical description of a box definition 


А 
B: u32 (c) D 


8 Binary format of a box 


Each box shall have the structure indicated in Table 4. This structure consists of a header indicating size and 
box type, and box content. 


NOTE1 This format is also specified in ISO/IEC 15444-1:2019 and ISO/IEC 15444-2:2021. 


Table 4 — Binary format of a box 


Box header Box content | 


LBox: u32 [TBox: 4 bytes |(XLBox: u64) |DBox: remaining bytes 


The fields given in Table 4 are the following: 


— LBox: has type u32. Gives the size of the box in bytes, including the box header fields. If the value is 1, 
then XLBox is used instead to indicate the size of the box. If the value is 0, then this box is the last box of 
the file, and its data extends to the end of the file. If the value is not 0 or 1, it shall be at least 8. 


— TBox: has 4 bytes (e.g. a FourCC code): box type, specifies the type of information found in the box 
content, e.g. whether it is a JPEG XL Signature box, а File Type box, and so оп. 


— XLBox: has type u64. Only present if LBox == 1. If present this field, instead of the LBox field, indicates 
the size of the box in bytes. Its value shall be at least 16. 


— DBox: has the remaining bytes. The box content (data). The content is formed by all the remaining bytes 
of the box. The size of the content in bytes is the box size minus the size of the box header fields. The 
format and meaning of this content is indicated by the box type, and Clause 9 defines the format of the 
contents that may appear in a JPEG XL file. 


NOTE2 Тһе box size is a multiple of bytes. This includes the JPEG XL codestream box. The JPEG XL codestream is 
zero-padded at the end to align to a byte. 


9 Box types 


9.1 JPEG XL Signature box 
The JPEG XL signature box shall contain exactly the following 12 bytes, given as hexadecimal numbers: 


= 0x00 0x00 0x00 0x0C 
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— ox4a 0x58 0х4с 0x20 (the box type `JXL ` in ASCII) 
= 0х00 Ox0A 0x87 0х0А 


A JPEG XL file shall contain exactly one signature box. The signature box shall be the first box. 


9.2 File Type box 

The file type box shall contain exactly the following 20 bytes: 
— 0x00 0x00 0x00 0x14 

— 0x66 0x74 0x79 0x70 (the box type ftyp in ASCII) 

— 0x6A 0x78 Ox6C 0x20 (`jxl` in ASCII) 

— 0x00 0x00 0x00 0x00 

— 0x6A 0x78 0x6C 0x20 (`jxl` in ASCII) 


AJPEG XL file shall contain exactly one file type box. The file type box shall be the second box. The profile of 
the codestream box contained in this file is the Main profile. 


9.3 Level box 
The type of this box shall be given by the 4 bytes 0x6 0x78 0x6c 0x6c (x11 in ASCII). 


Table 5 shows the contents of a Level box, excluding the box header. 


Table 5 — Content of a Level box 


A JPEG XL file shall contain at most one Level box. If it is present, it shall be the third box, immediately after 
the file type box. 


If there is no Level box, the level is assumed to be 5. This level applies to the content of the JPEG XL codestream 
box, as described in ISO/IEC 18181-1:2024, Annex M. 


9.4 JUMBF box 


The type of this box shall be given by the 4 bytes 0x6A 0x75 0x6 0x62 (jumb in ASCII). This box shall follow 
the specification defined by ISO/IEC 19566-5. 


A JUMBF box is a superbox that shall contain exactly one JUMBF Description box followed by one or more 
Content Boxes. 


9.5 Exif box 
The type of this box shall be given by the 4 bytes 0x45 0x78 0x69 0x66 (Exif in ASCII). 


Table 6 shows the contents of an Exif box, excluding the box header. 


Table 6 — Content of an Exif box 


tiff header offset: u32 _|Exif payload: remaining bytes ] 


The Exif payload is as described in JEITA CP-3451E or JEITA CP-3461B. The tiff header offset denotes, as 
specified in JEITA CP-3461B, the number of bytes, counting from the first byte of the Exif payload to the first 
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byte of the TIFF header of the Exif metadata. The value is zero if the payload starts immediately with the 
TIFF header. 


NOTE1 The content of this box is exactly ExifDataBlock as defined in ISO/IEC 23008-12:2022, Annex A.2. 


For any Exif fields that have equivalents within the codestream, a decoder shall consider the codestream to 
take precedence. Encoders are encouraged to ensure the Exif and codestream fields are identical. 


NOTE2 Examples of such fields include orientation and pixel dimensions. 
9.6 XML box 
The type of this box shall be given by the 4 bytes 0x78 0x6D 0x6c 0x20 ("xml ` in ASCII). 
The XML box contains a well-formed XML document as defined by W3C REC-xml-20081126. 
Table 7 shows the content of an XML box. 
Table 7 — Content of an XML box 

[XML data: all bytes 

AJPEG XL file may contain multiple XML boxes. 


NOTE This box follows the specification of XML Box in ISO/IEC 15444-2:2021. 


9.7 Brotli-compressed box 
The type of this box shall be given by the 4 bytes 0x62 0x72 0x6F 0x62 (brob in ASCII). 


Table 8 shows the contents of a Brotli-compressed box, excluding the box header. 


Table 8 — Content of a Brotli-compressed box 


payload box type: 4 bytes _|Brotli-compressed payload: remaining bytes 


This box shall be treated as if it is a box of the type given by the first 4 bytes of its contents (the payload 
box type), with a contents equal to the Brotli-decompressed data obtained from the remaining bytes. The 
payload box type shall not be 0x62 0x72 0x6 0x62 (brob) and shall not start with 0x6A 0x78 0х6с (3х1) пог 
be equal to 0x6A 0x62 0x72 0x64 (jbrd). 


Brotli-compressed data shall be decoded as specified in IETF RFC 7932. 


9.8 Frame Index box 
The type of this box shall be given by the 4 bytes 0x6 0x78 0x6¢ 0x69 (jx1i in ASCII). 


This box contains an index of animation frame offsets. This box is optional and allows a decoder to efficiently 
seek the data of a frame based on time or frame order. Not all frames are necessarily listed in the index. All 
frames listed in the index shall be “keyframes”. The first frame shall always be listed. Keyframes are defined 
such that when a decoder seeks to the beginning of this frame, the result of decoding this frame and future 
frames is the same as when the decoder starts from the beginning. This implies that the current frame does 
not use earlier frames for features such as blending, patches or 1*_1еуе1, and later frames can only refer to 
this frame or later for these features. The JPEG XL codestream supports frames with a duration of 0 ticks. 
These frames are not presented by the decoder but can be used to form composite frames such as through 
blending. Such frames are not counted as frames for the purpose of the F; fields listed in Table 9, but the 
offset can point to such frames, as they are required for decoding the full composite frame and may form the 
beginning of a composite keyframe. 


The box content shall have the structure indicated in Table 9 and further described below. In this table, all 
fields have type Varint() unless indicated otherwise. 
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Table 9 — Content of a Frame Index box 


[NE [wun u32 (Toen: u32 [OFF [Ty [Fo |. Тов [Тай [Ever 
The fields in Table 9 shall be interpreted as follows: 


— МЕ: has type Varint(); number of frames listed in the index. 

— Туум: has type u32: numerator of tick unit. 

— Tpey: has type u32: denominator of tick unit. If this value is 0, the file is ill-formed. 
- per frame i listed: 


— OFF; has type Varint(); offset of start byte of this frame compared to start byte of previous frame 
from this index in the JPEG XL codestream. For the first frame, this is the offset from the first byte of 
the JPEG XL codestream. 


- Tj: has type Varint(): duration in ticks between the start of this frame and the start of the next frame 
in the index. If this is the last frame in the index, this is the duration in ticks between the start of this 
frame and the end of the stream. А tick lasts Туум / Tpen Seconds. 


— Fj: has type Varint(): amount of frames the next frame in the index occurs after this frame. If this 
is the last frame in the index, this is the amount of frames after this frame in the remainder of the 
stream. Only frames that are presented by the decoder are counted for this purpose, this excludes 
frames that are not intended for display but for compositing with other frames, such as frames that 
aren't the last frame with a duration of 0 ticks. 


Itis the responsibility of the creator of the file to ensure the frame index box corresponds to the codestream, 
in particular that the offsets point to the correct location of the corresponding frame, the frames are 
keyframes and the first frame is present in the list. 


There shall be either zero or one Frame Index boxes in a JPEG XL file. 


The Frame Index box may come before or after partial codestream boxes. Encoders are encouraged to write 
the frame index before the codestream, but the codestream header before the frame index, if possible. 


NOTE1 Ifthe Frame Index box appears before the frames of the codestream, a streaming decoder would be able to 
issue range requests for an individual frame. Ifa partial codestream precedes the frame index box, it would preferably 
be small, for example containing only the codestream header and a preview image, which is useful to get image 
dimensions and preview from the earliest bytes of the file. 


NOTE2 The offsets OFF, per frame are given as bytes in the codestream, not as bytes in the file format using the 


box structure. This means if JPEG XL Partial Codestream boxes (as defined in subclause 9.10) are used, the offset is 
counted within the concatenated codestream, bytes from box headers or non-codestream boxes are not counted. 


9.9 JPEG XL Codestream box 


The type of this box shall be given by the 4 bytes 0x6 0x78 0x6c 0x63 (jx1c in ASCII). Its contents shall be 
the codestream described in ISO/IEC 18181-1. 


A JPEG XL file shall contain either exactly one JPEG XL codestream box, or one or more JPEG XL partial 
codestream boxes, but not both. 


Encoders are encouraged to place any metadata that might affect rendering before the partial or full 
codestream. 


9.10 JPEG XL Partial Codestream box 


The type of this box shall be given by the 4 bytes 0x6a 0x78 0x6c 0x70 (jx1p in ASCII). Its contents shall 
contain an index and a part of the codestream described in ISO/IEC 18181-1. Table 10 shows the contents of 
а JPEG XL Partial Codestream box, excluding the box header. 
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Table 10 — Content of a JPEG XL Partial Codestream box 
[index: u32 [Partial codestream payload: remaining bytes | 


This type of box allows to split the codestream into multiple parts. When partial codestream boxes are 
used, the full codestream is formed by the concatenation of the partial codestream payload of all partial 
codestream boxes in order of increasing index. The index modulo 23! shall be 0 for the first partial 
codestream box, and incremented by 1 for each next partial codestream box. The index shall be lower than 
231, except for the last partial codestream box, which shall have an index of at least 231. The boxes shall 
appear in the file in order of increasing index. The full concatenation of all partial codestream boxes in this 
order shall form exactly one complete and valid JPEG XL codestream. 


A JPEG XL file shall contain either exactly one JPEG XL codestream box, or one or more JPEG XL partial 
codestream boxes, but not both. 


Encoders are encouraged to place any metadata that might affect rendering before the partial or full 
codestream. 


NOTE 1 Splitting the codestream into multiple parts allows placing the first part of the codestream (e.g. the header 
and preview) early in the file, followed by possible metadata boxes, followed by the main part of the codestream. 


NOTE2 Partial codestream boxes can have an empty payload. 


9.11 JPEG Bitstream Reconstruction Data box 
The type of this box shall be given by the 4 bytes 0x64 0x62 0x72 0x64 (jbra in ASCII). 


This subsection uses the same notation conventions as in ISO/IEC 18181-1. The decoder reads the fields 
listed in Table 11 (which refers to bundles defined in Tables 12 to 18). 


Table 11 — JPEGBitstream bundle 


‘condition type default [name 
Bool() is_grey 
0хс0 + Bits(6) marker [0] 
0xC0 + Bits(6) marker [1] 
= 0xD9; 
|AppMarker app_marker[num_app_markers] 
1 + Bits(16) com_length {num_com_markers] 
1 + Bits(2) num _quant_tables 
QuantTable quant [num_quant_tables] 
Bits(2) comp_type 
comp_type == 3 1 + Bits(2) numc = |num_comp 
comp_type Bits(8) а іа |component_id[num_comp] 
Bits(2) component_q_idx[(num_comp] 
U32(Val(4), BitsOffset(3, 2), num_huff 
BitsOffset(4, 10), BitsOff- 
set(6, 26)) 
HuffmanCode huffman_code [num_huff] 
ScanInfo scan_info[num_scans] 
has_dri Bits(16) 0 restart_interval 
ScanMorelnfo Scan_more_info[num_scans] 
Bits(16) intermarker_length[num_intermarker] 
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Table 11 (continued) 

condition type default [name 

U32(Val(0), BitsOffset(8, 1), tail_data_length 

BitsOffset(16, 257), BitsOff- 

set(22, 65793) 

Bool() has_padding 
has_padding Bits(24) 0 mbit 

Bool() bbit [nbit] 


Here marker is an array of integers, and num_app_markers is the number of occurences of a number between 
0xE0 and 0xEF in this array, num_com_markers is the number of occurrences of the number 0xFE, num_scans is 
the number of occurrences of the number охра, num_intermarker is the number of occurrences of the number 
охғғ, and has_dri is true if the number Охоо occurs. 


The default number of components nume is equal to 1 if comp_type == 0 and З otherwise. The default 
component identifiers а : 2 is equal to {1} if comp type == 0, to {1,2,3} if comp_type == 1, and to {'R', ‘G', ‘B’} 
if comp_type == 2. 


Table 12 — AppMarker bundle 


condition type default] name | 
U32(Val(0), Val(1), BitsOffset(1, 2), BitsOffset(2, 4)) type | 
1 + Bits(16) length | 


Table 13 — QuantTable bundle 


condition | type | default name 
Bits(1) precision 
Bits(2) index 
Bool() is last 


Table 14 — HuffmanCode bundle 


condition type default name 
Bool() is_ac 
Bits(2) id 
Bool() is_last 
U32(Val(0), Val(1), BitsOffset(3, 2), Bits(8)) counts [16] 
U32(Bits(2), BitsOffset(2, 4), BitsOffset(4, 8), BitsOffset(8, 1)) values [sum(counts) ] 


Table 15 — ScanInfo bundle 


condition type default name 
1+ Bits(2) num_comps 
Bits(6) 5з 
Bits(6) зе 
Bits(4) А1 
Bits(4) Ah 
ScanComponentInfo component [num_comp] 


last_needed pass 


U32(Val(0), Val(1), Val(2), BitsOffset(3, 3)) 
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Table 16 — ScanComponentinfo bundle 


condition type default name 
Bits(2) ‘comp_idx 
Bits(2) ac_tbl_idx 
Bits(2) dc_tbl_idx 


Table 17 — ScanMoreInfo bundle 


condition type default name 


U32(Val(0), BitsOffset(2, 1), BitsOffset(4, 4), 
BitsOffset(16, 20) 


U32(Val(0), BitsOffset(3, 1), BitsOffset(5, 9), reset_point (num_reset_points] 
BitsOffset(28, 41)) 

U32(Val(0), BitsOffset(2, 1), BitsOffset(4, 4), num_extra_zero_runs 

BitsOffset(16, 20)) 

ExtraZeroRun extra_zero_run(num_extra_zero_runs] 


Table 18 — ExtraZeroRun bundle 


condition | type [default] __ name 
U32(Val(1), BitsOffset(2, 2), BitsOffset(4, 5), BitsOffset(8, 20)) num_runs 
U32(Val(0), BitsOffset(3, 1), BitsOffset(5, 9), BitsOffset(28, 41)) run_length 


After reading these fields, the decoder decompresses a single Brotli stream as specified in IETF RFC 7932. 
The decompressed stream contains a concatenation of the following data: 


— First the contents of every unknown app marker: for i from 0 to num_app_markers - 1,ifapp_marker[i]. 
type is 0, then арр _marker[i].length bytes are given corresponding to APPn segment арр даса [1] 
(otherwise the bytes will be provided in a different way); 


— Then for i from 0 to num_com_markers ~ 1, there are com_length [i] bytes corresponding to COM segment 
com_datalil; 


Then for + from 0 to num intermarker - 1, there are intermarker_length{i] bytes corresponding to 
unrecognized segment intermarker_data [i]; 


— Finally, there are tail data length bytes which denoted as tail data. 
The procedure to reconstruct a JPEG bitstream based on the data contained in the JPEG Bitstream 


Reconstruction Data box (as well as the JPEG XL Codestream box and potentially other boxes) is specified in 
Annex A. 
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Annex А 
(normative) 


JPEG Bitstream Reconstruction procedure 


A.1 General 


The reconstructed JPEG bitstream is produced as a concatenation of {0xFF, 0x08} bytes (implicit SOI segment) 
and a sequence of segments, generated on the basis of the elements of the marker array. Element values 
determine the type of the corresponding segment. Detailed instructions for various type values are specified 
in subclauses. If the encountered type does not match any instruction, then the codestream is ill-formed. 


app_data, com_data, inter_marker_data, huffman_code, quant, bbit and scan_info members are accessed 
through “iterators”; this means that during JPEG reconstruction every element (referenced as “next”) is used 
exactly once and in order of increasing index. 


A.2 SOF segment 
“Start Of Frame” segment. 
type is one of {0xC0, 0xC1, 0xC2, 0xC9, Oxca}. 


This segment starts with 10 bytes: (0xFF, type, len_hi, len_lo, 8, height_hi, height_lo,width_hi, width_lo, 
num_comp}, Where hi and _1o denote the highest and lowest 8 bits of the corresponding values, len is the 
final length of this segment minus 2, and height and width are the image dimensions (see D.2. 


For each of the поп сотр components, 3 more bytes are appended to this segment: {component_id[il, (h_ 
samp_factor[i] << 4) | v_samp_factor[i], component_q_idx[i]}, where h_samp factor (v_samp_factor) is 
the horizontal (vertical) sampling factor of the corresponding component according to the jpeg_upsamp1ing 
field (see Е.2) — note that in case of YCbCr, the order is Cb, Y, Cr in the jpeg_upsamp1ing field while it is Y, Cb, 
Cr in the reconstructed JPEG bitstream. 


А.З DHT segment 
“Define Huffman Table(s)" segment. 


type is 0хС4. 


In this segment a series of HuffmanCode entities are serialized. Entities are fetched from the next һоғғпап 
code until the element with is_last == true is reached. 


This segment starts with 4 bytes: {0xFF, 0xc4, len_hi, Іеп 10}, where 1еп һі and 1еп 1 
lowest 8 bits of the final length of this segment minus 2. 


are the highest and 


For each HuffmanCode entity hc, the segment content is defined in ISO/IEC 10918-1:1994, Annex B.2.4.2, 
with the following mapping: 


— Tc together with Th, encoded аз а single byte, is hc. id 


— Lyarecorrespondinghc. counts elements, except for the last non-zero element, which shall be decremented 
by 1, before storing 


— (flattened) V; j are corresponding he. values elements 
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A.4 RSTn segment 
“Restart” segment. 
type is in the range [0xD0, 0xD8). 


This segment contains 2 bytes: (0xFF, type}. 


A.S EOI segment 
“End Of Image” segment; this is the last segment. 
type is 0xD9. 


This segment starts with {охЕЕ, 0xD9} bytes. The rest of the segment is copied from tail data. 


A.6 SOS segment 
“Start Of Scan” segment. 
type is oxpa. 


Let зі be the next scan_info element, smi be the next scan_more_info element, num_comps = si.num_comps, 
and len = 6 + 2 * num_comps. 


This segment starts with {0xFF, 0xDA, len_hi, len_lo, num_comps} bytes, where len_hi and len_lo are the 
highest and lowest 8 bits of 1e. 


For each si.component element csi, the segment content is defined in ISO/IEC 10918-1:1994, Annex B.2.3, 
with the following mapping: 


— Csjiscomponent_id[csi.comp_idx] 
— Tdyiscsi.de_tbl_idx 
— Tajiscsi.ac thi idx 


The next 3 bytes of this segment are also defined in ISO/IEC 10918-1:1994, Annex B.2.3, with the following 
mapping: Ss is si .5s, Se is si.Se, Ah is si .Ah, and Alis si .А1. 


The DCT coefficient data is encoded according to ISO/IEC 10918-1:1994 with the following changes to enable 
unambiguous bit-precise JPEG stream reconstruction: 


— ifhas_padding then making entropy-coded segments (ISO/IEC 10918-1:1994, Annex B.1.1.5) an integer 
number of bytes is performed as follows: next bits from ъъ: + are used, if necessary, to pad to the end of 
the compressed data to complete the final byte of a segment (otherwise these padding bits are zero); 


— when encoding AC coefficients for sequential DCT (ISO/IEC 10918-1:1994, Annex F.1.2.2.1), ezr.num_ 
runs extra “ZRL" symbols are emitted before processing the end-of-block, where ezr is the smi.extra_ 
zero_run element whose block_idx member matches the currently serialized block index (in the current 
scan); the final “EOB” symbol is emitted only if the number of 0 coefficients remaining to be encoded is 
non-negative; 


— when encoding AC coefficients for progressive DCT (ISO/IEC 10918-1:1994, Annex G.1.2.2), ezr.num_ 
runs extra “КІ” symbols are emitted before updating “ЕОВКОМ”, where ezr is the smi.extra_zero_run 
element whose block_idx member matches the currently serialized block index (in the current scan); 


“EOBRUN" is updated only if the number of 0 coefficients remaining to be encoded is non-negative 


— before encoding the block, if the block with the currently serialized block index (in the current scan) 
is present in the ‘smireset_poin't set, then “Encode EOBRUN” is invoked (ISO/IEC 10918-1:1994, 
Annex G.1.2.2). 
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A.7 "РОТ segment 
“Define Quantization Table(s)" segment. 
type is 0xDB, 


In this segment a series of QuantTable entities are serialized. Series of items are fetched from the next quant 
until the element with is last == true is reached. 


This segment starts with {0xFF, 0x08, Len_hi, 1еп 10) bytes, where ien_ni and ien_1o are the highest and 
lowest 8 bits of the final length of this segment minus 2. 


For each QuantTable element а, the serialized content is defined in ISO/IEC 10918-1:1994, Annex B.2.4.1, 
with the following mapping: 


— Pqisq-precision 
— Mais а. index 


— Q are corresponding quantization factors from the JPEG XL codestream (1.2.4). If there are no 
corresponding quantization factors (which implies that this is an unused quantization table), the factors 
are to be considered identical to those of the previous QuantTable element. 


A.8 DRI segment 

"Define Restart Interval" segment. 

type is 0xDD. 

This segment contains {0xFF, 0xDD, 0x00, 0x04, hi, lo} bytes, where hi and 1o are the highest and lowest 8 bits 
Of restart_interval. 

А.9 APPn segment 

“Application-specific” segment. 

type is in the range [0xE0, 0xF0). 

This segment starts with the {охЕЕ} byte. Let am be the next арр па . If am. type is 0, then the rest of the 


segment is copied from the corresponding арр азса element. If it has a different type, then this segment is 
constructed as follows: 


If am. type is 1 (ICC profile), then the next bytes аге {охЕ2, 1en_hi, 1en_1o}, where 1en_hi and 1en_1o are the 
highest and lowest 8 bits of am. 1ength - 1, followed by the zero-terminated ASCII string “ICC_PROFILE”, 
followed by the u(8) index among all app markers of type 1 (counting from 1), followed by the u(8) total 
number of app markers of type 1, followed by the next fragment of the decoded ICC profile (as described in 
E.4) of length am. length - 17. 


If am.type is 2 (Exif metadata) or З (XMP metadata), then the next bytes are {0x#1, 1en_hi, 1en_1o}, where 
len_hi and 1еп_1о аге the highest and lowest 8 bits of am. Length - 1. Then if the type is 2, this is followed 
by the zero-terminated string “Exif”, followed by another zero, followed by the payload of the (next) Exif box 
(9.5) not including the tiff header offset, or a Brotli-compressed equivalent (9.7). If the type is 3, then this is 
followed by the the zero-terminated string “http://ns.adobe.com/xap/1.0/", followed by the payload of the 
(next) XML box (9,6) or a Brotli-compressed equivalent (9.7). 


A.10 COM segment 
“Comment” segment. 


type is 0xFE. 
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The segment starts with {oxrr, 0хЕЕ} bytes. The rest of the segment is copied from the next сот аа element. 


A.11 Unrecognized data segment 
Unrecognized JPEG pieces are stored as raw unrecognized data segments. 
type is 0xFF. 


The segment contents are copied from the next inter_marker_data element. 
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Annex B 
(normative) 


JPEG XL Media Type registration 


B.1 General 


This annex provides a media type registration following IETF RFC 6838. 


B.2 Registration 

Media type name: image 

Media subtype name: jx! 
Required parameters: none 
Optional parameters: none 
Encoding considerations: binary 


Files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping 
etc.; base64 is a suitable encoding. 


Security considerations: 


The conveyed coded image files defined in ISO/IEC 18181-2 use a structure that can store image data, 
metadata corresponding to this image data, and other user-defined data. The data files have an extensible 
structure, so that it is theoretically possible that metadata fields are defined in the future that can be used to 
induce particular actions on the part of the recipient, thus presenting additional security risks, but this type 
of capability is currently not supported in the current referenced specifications. 


Image dimensions can be large, and image files can contain multiple frames as well as many components. A 
small compressed file could decode to a large uncompressed object, which can lead to out of memory failure 
conditions. Additionally, it can potentially take significant computational effort to decode even an image file 
that has a small compressed or uncompressed size, potentially leading to denial-of-service issues. However, 
it should be possible to implement a conforming decoder that has bounded memory usage and that runs іп a 
bounded amount of time for a given image size, so this is a matter of quality of implementation rather than 
an inherent security risk. 


Interoperability considerations: 


JPEG XL image files can conform to a profile and level of capabilities (as specified in ISO/IEC 18181-1:2024, 
Annex М) - not all of which may be supported by a receiving decoder. As a result, implementations may 
attempt to decode and display an encoded JPEG XL image only to determine that the image cannot be 
rendered, either partially or in full. 


JPEG image files (ISO/IEC 10918-1:1994) can be losslessly recompressed to JPEG XL images (with improved 
compression), and the original JPEG file can be reconstructed using the JPEG Bitstream Reconstruction Data 
as described in ISO/IEC 18181-2. 


Published specifications: 
ISO/IEC 18181-2 


Applications: Multimedia, Imaging, Pictures, Scientific 
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Fragment identifier considerations: None 
Additional information: 

Deprecated alias names for this type: N/A 
Magic number(s): 


Starts with either the 2-byte sequence охЕЕ ол (a direct JPEG XL codestream without box structure) or the 
12-byte sequence 0x0000 000c 4A58 4С20 0DOA 870A (an ISOBMFF box structure starting with the JPEG XL 
Signature box), as specified in ISO/IEC 18181-2. 


File extension(s): jx! 

Macintosh File Type Code(s): N/A 
Intended usage: COMMON 
Restrictions on usage: None 
Author: ISO/IEC JTC 1 / 5С 29 / WG 1 
Change controller: ISO/IEC JTC 1 
Other general information: 


It should be noted that selected metadata fields may encompass information partly intended to protect the 
image against unauthorized use or distribution. In this case, the intention may be that alteration or removal 
of the data in the fields would be treated as an offence. Metadata fields may also contain information about 
the source of the image content. 
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